build: fall back to previous image version on release PRs#12848
build: fall back to previous image version on release PRs#12848
Conversation
There was a problem hiding this comment.
Code Review
This pull request introduces a fallback mechanism for the hermetic library generation script. When a release PR branch is detected, the script attempts to pull the specified Docker image; if it fails, it tries to extract and use the image tag from the target branch's workflow configuration. The review feedback suggests improving the robustness of the tag extraction logic to better handle potential multiple matches, comments, or colons within the YAML file.
6880d59 to
def6f2d
Compare
The library generation pipeline fails on release PRs because it attempts to pull a Docker image version that has not yet been built or pushed to the registry. This PR adds a fallback mechanism in hermetic_library_generation.sh to use the previous version of the image from the main branch if the requested version fails to pull on a release PR. To verify this in CI, this branch is named with the prefix 'release-please--' to simulate a release PR. Fixes #12825
def6f2d to
823b98c
Compare
|
Fallback validated in a separate release simulation PR #12849: |
|
|
||
| # run hermetic code generation docker image. | ||
| # Attempt to pull the image to see if it exists on release PRs. | ||
| if [[ "$current_branch" =~ ^release-please-- ]]; then |
There was a problem hiding this comment.
We could create release-please PRs from CLI as well.
There was a problem hiding this comment.
That's fine, as long as the branch prefix is release-please--.
There was a problem hiding this comment.
But that means we have to remember using release-please-- as the branch name, is there any harm we do this for every branches?
There was a problem hiding this comment.
You shouldn't have to use the Release Please CLI going forward which should eliminate the need to remember the branch prefix. The risk of always falling back is that if someone configures and invalid generator version, they won't get a CI failure as feedback.
suztomo
left a comment
There was a problem hiding this comment.
Approving but please consider whether to use the "latest" tag.
@suztomo I think using the version in the target branch is more robust because it allows the code to support multiple branches with different versions of the generator. |
9a162ab to
ef92609
Compare
| @@ -1,4 +1,3 @@ | |||
| gapic_generator_version: 2.70.0 | |||
There was a problem hiding this comment.
@blakeli0 Note that I'm removing this version declaration because it's confusing as it doesn't get updated, and it's not used anyway.
There was a problem hiding this comment.
Agreed. We used to update this version in the daily generation PR to trigger a full generation, but we always use the latest snapshot version now after monorepo migration.
There was a problem hiding this comment.
Do you intend to fix this file in the split repositories?
E.g, https://github.com/googleapis/java-firestore/blob/main/generation_config.yaml#L1
There was a problem hiding this comment.
I think it's OK to wait until the other repos migrate to the monorepo.
There was a problem hiding this comment.
Yep, this is resulted from monorepo migration. I don't think we want to do it for split repos.
…gle-cloud-java into release-please--fix-12825
| ENV OS_ARCHITECTURE="linux-x86_64" | ||
|
|
||
| # {x-version-update-start:gapic-generator-java:current} | ||
| ENV GENERATOR_VERSION="2.71.0" |
There was a problem hiding this comment.
I don't think this is needed?
There was a problem hiding this comment.
Yes, sdk-platform-java/hermetic_build/common/model/generation_config.py has a method __set_generator_version that checks if the gapic_generator_version is specified in the YAML file. If it is not specified in the YAML, the code falls back to reading the GENERATOR_VERSION env var.
There was a problem hiding this comment.
I see. We are already setting it in the CI hermetic_library_generation.yaml though, so this is for scenarios that are not triggered through CI?
| @@ -1,4 +1,3 @@ | |||
| gapic_generator_version: 2.70.0 | |||
There was a problem hiding this comment.
Agreed. We used to update this version in the daily generation PR to trigger a full generation, but we always use the latest snapshot version now after monorepo migration.
|
|



The library generation pipeline fails on release PRs because it attempts to pull a Docker image version that has not yet been built or pushed to the registry.
This PR adds a fallback mechanism in hermetic_library_generation.sh to use the previous version of the image from the main branch if the requested version fails to pull on a release PR.
To verify this in CI, this branch is named with the prefix 'release-please--' to simulate a release PR.
Fixes #12825